% !Mode:: "TeX:UTF-8"

\chapter{软件需求规格说明书}

\section{引言}
\subsection{目的}
本需求规格说明书旨在定义“饿了吧V2.0”外卖点餐平台的功能性和非功能性需求。该文档将为开发团队、测试团队和项目管理人员提供指导，确保产品开发的各个阶段都能遵循明确的需求规格，最终实现高质量的软件交付。

\subsection{项目范围}
“饿了吧V2.0”是一个线上点餐平台，连接消费者与本地餐馆，提供用户注册、商品浏览、在线点餐、支付以及配送跟踪等功能。该项目计划升级现有系统，扩展用户管理、商家管理、订单管理等模块，同时提高系统性能和用户体验。

\subsection{定义和缩写}
\begin{itemize}
\item{API(Application Programming Interface)}: 应用程序编程接口，用于前后端数据交互。
\item{VUE3}: JavaScript框架，用于构建用户界面。
\item{Spring Boot}: 基于Java的微服务开发框架，用于构建后端服务。
\item{MySQL}: 开源的关系型数据库管理系统，用于数据存储。
\end{itemize}
\subsection{参考资料}
\begin{itemize}
  \item “饿了吧V1.0”项目文档与代码库
  \item Java EE开发手册
  \item RESTful API设计规范
\end{itemize}

\section{总体描述}
\subsection{产品概述}
“饿了吧V2.0”平台的主要功能是为用户提供一个便捷的在线订餐和配送服务渠道。系统将通过Web和移动应用两种形式提供服务，支持用户浏览商家及其商品、在线下单支付，并实时跟踪订单状态。商家端提供商品管理、订单处理、数据分析等功能。管理员则负责用户管理、商家审核和系统维护。

\subsection{产品功能}
\begin{itemize}
  \item 用户管理: 支持用户的注册、登录、地址管理等功能。

  \item 商家管理: 提供商家注册、店铺信息登记、商品管理和订单处理功能。

  \item 点餐功能: 用户可以浏览商家菜单、将商品添加至购物车、下单并支付订单。

  \item 支付功能: 支持通过支付宝等第三方支付平台进行模拟支付。

  \item 订单管理: 实现订单的生成、支付和历史订单查询功能。
\end{itemize}
\subsection{用户特性}
1. 消费者
\begin{itemize}
  \item 目标用户：希望通过互联网进行餐饮订购的个人用户。
  \item 具备基础的计算机和手机操作能力。
  \item 用户通过手机或电脑浏览附近的餐馆，选择商品下单，并完成支付和配送跟踪。
\end{itemize}

\begin{itemize}
  \item 希望通过线上平台扩展销售渠道的餐饮店铺。
  \item 熟悉基本的后台操作，能够管理店铺信息和处理订单。
  \item 商家通过平台管理店铺，上传和更新商品信息，处理用户订单并组织配送。
\end{itemize}

\subsection{约束条件}
\begin{itemize}
  \item 时间约束: 项目必须在三周内完成开发并上线，时间非常紧张。
  \item 系统前端必须使用VUE3框架，后端使用Spring Boot框架，数据库采用MySQL。
\end{itemize}
\section{功能性需求}
\subsection{用户管理}
\subsubsection{用户注册}
用户注册流程图如图~\ref{fig:1}~所示。
\begin{figure}[htbp]
\centering
\includegraphics[width=0.4\textwidth]{1}
\caption{用户注册流程图}\label{fig:1}
\vspace{\baselineskip}
\end{figure}

功能描述: 用户可以通过手机号注册账号。注册后，用户可以使用账号登录系统。

输入: 用户提供手机号、密码、用户名、性别。

处理流程:

  1. 用户输入注册信息。

  2. 生成用户账号并存储在数据库中。

  3. 用户输入账号和密码，登录系统。

输出: 注册成功后，系统提示注册成功，并跳转到登录页面。
\subsubsection{用户登录}
用户登录流程图如图~\ref{fig:2}~所示。
\begin{figure}[htbp]
\centering
\includegraphics[width=0.4\textwidth]{2}
\caption{用户登录流程图}\label{fig:2}
\vspace{\baselineskip}
\end{figure}

功能描述: 用户可以通过手机和密码登录系统。

输入: 用户提供手机号、密码。

处理流程:

1. 用户输入用户信息。

2. 与数据库中的账号密码匹配。

3. 若匹配成功，用户登录系统。

输出: 登录成功后，跳转到“我的”页面。
\subsubsection{地址管理}
地址管理流程图如图~\ref{fig:3}~所示。
\begin{figure}[htbp]
\centering
\includegraphics[width=0.4\textwidth]{3}
\caption{地址管理流程图}\label{fig:3}
\vspace{\baselineskip}
\end{figure}

功能描述: 用户可以添加、修改或删除送货地址。

输入: 地址信息（如联系人、电话、地址等）。

处理流程:

1. 用户在地址管理页面添加或修改地址。

2. 数据库更新用户的地址信息。

输出: 地址管理页面显示更新后的地址列表。
\subsection{商家管理}
商家管理流程图如图~\ref{fig:4}~所示。
\begin{figure}[htbp]
\centering
\includegraphics[width=0.3\textwidth]{4}
\caption{商家管理流程图}\label{fig:4}
\vspace{\baselineskip}
\end{figure}
\subsubsection{商家注册}
功能描述: 商家可以注册新账户并登录平台，进入后台管理系统。

输入: 商家信息（店铺名称、联系人信息、地址等）。

处理流程:

1. 商家点击我是商家按钮。

2.商家填写注册表单。

3.点击提交入驻申请按钮

输出: 填写成功后，跳转至“我的”界面。

\subsubsection{商品管理}
功能描述: 商家可以添加和删除店铺内的商品信息，包括商品名称、价格、描述、库存等。

输入: 商品信息（如名称、价格、库存）。

处理流程:

  	1. 商家在商品管理页面添加或修改商品。

  	2. 系统检查信息的完整性。

  	3. 数据库更新商品信息。

输出: 前台页面显示更新后的商品列表。
\subsection{点餐功能}
点餐功能流程图如图~\ref{fig:5}~所示。
\begin{figure}[htbp]
\centering
\includegraphics[width=0.6\textwidth]{5}
\caption{点餐功能流程图}\label{fig:5}
\vspace{\baselineskip}
\end{figure}
\subsubsection{菜单浏览}
功能描述: 用户可以浏览商家的菜单，查看商品的详细信息、价格和库存状态。

输入: 无。

处理流程:

 	1. 用户进入商家店铺页面。

  	2. 系统从数据库读取商家商品信息并展示给用户。

输出: 菜单页面显示商品列表和详情。
\subsubsection{添加商品至购物车}
功能描述: 用户可以将选中的商品添加到购物车，准备下单。

输入: 商品的ID、数量。

处理流程:

  	1. 用户在菜单页面选择商品并点击“加入购物车”按钮。

  	2. 系统检查商品的库存是否足够，若库存充足，则将商品添加到购物车。

  	3. 系统更新购物车中的商品列表。

输出: 购物车页面显示最新的商品列表和总金额。
\subsubsection{订单生成与支付}
功能描述: 用户可以提交购物车中的商品生成订单，并选择支付方式进行支付。

输入: 购物车中的商品信息、配送地址、支付方式。

处理流程:

  	1. 用户在购物车页面确认商品列表和配送信息，点击“提交订单”按钮。

  	2. 系统生成订单记录，并为用户提供支付接口。

  	3. 用户选择支付方式（如支付宝）并完成支付。

  	4. 系统验证支付结果，并更新订单状态为“已支付”。

输出: 订单页面显示订单编号和支付状态，并发送订单确认信息。
\subsection{支付功能}
支付功能流程图如图~\ref{fig:6}~所示。
\begin{figure}[htbp]
\centering
\includegraphics[width=0.6\textwidth]{6}
\caption{支付功能流程图}\label{fig:6}
\vspace{\baselineskip}
\end{figure}
\subsubsection{支付功能模拟}
功能描述: 系统需要模拟第三方支付平台（如支付宝）以处理用户的支付请求。

输入: 支付请求（包括订单金额、支付方式等）。

处理流程:

  	1. 用户提交支付请求。

  	2.平台处理支付请求，并返回支付结果。
    
输出: 系统根据支付结果更新订单状态，并返回支付成功或失败的提示。
\subsection{订单功能}
订单功能流程图如图~\ref{fig:7}~所示。
\begin{figure}[htbp]
\centering
\includegraphics[width=0.5\textwidth]{7}
\caption{订单功能流程图}\label{fig:7}
\vspace{\baselineskip}
\end{figure}
\subsubsection{未支付订单查询}
功能描述: 可以返回未支付订单信息。

输入: 订单查询请求。
处理流程:

  	1. 返回未支付订单的内容和金额。

输出: 未支付订单的内容和金额。
\subsubsection{未支付订单支付}
功能描述: 对未支付订单进行支付。

输入: 点击去支付按钮。

处理流程:

1.跳转到支付页面。

2.选择支付方式。

3.确认支付。

输出: 支付成功。
\subsubsection{已支付订单查询}
功能描述: 可以返回已支付订单信息。

输入: 订单查询请求。
处理流程:

  	1. 返回已支付订单的内容和金额。

输出: 已支付订单的内容和金额。
\subsection{客服功能}
客服功能流程图如图~\ref{fig:8}~所示。
\begin{figure}[htbp]
\centering
\includegraphics[width=0.5\textwidth]{8}
\caption{客服功能流程图}\label{fig:8}
\vspace{\baselineskip}
\end{figure}
\subsubsection{客服对话}
功能描述：客服功能允许用户通过智能客服接口进行咨询和问题解答。系统将集成第三方AI服务，通过WebSocket与AI服务进行实时通信，以实现快速响应。

输入：用户输入的问题或请求。

处理流程：

1.用户通过客服按钮进入对话界面。

2.用户输入问题并提交。

3.后端通过WebSocket发送用户问题到AI服务。

4.AI服务处理问题并生成回复。

5.后端接收AI回复并将其展示给用户。

输出：智能客服生成的文本回复。
\subsection{积分功能}
积分功能流程图如图~\ref{fig:9}~所示。
\begin{figure}[htbp]
\centering
\includegraphics[width=0.4\textwidth]{9}
\caption{积分功能流程图}\label{fig:9}
\vspace{\baselineskip}
\end{figure}
\subsubsection{积分使用}
功能描述：积分模块允许用户通过购买商品获得积分，积分可以用于未来的订单折扣或兑换特定商品。系统将自动跟踪用户的积分，并提供积分兑换的接口。

输入：用户购买商品的信息，用户选择使用积分的信息。

处理流程：

1.用户购买商品后，系统自动计算并添加相应的积分到用户账户。

2.用户在结账时选择使用积分，系统将根据积分数量自动计算折扣。

3.系统更新用户的积分余额，并应用折扣到订单总额。

输出：用户当前的积分余额，使用积分后的订单折扣详情。
\section{非功能性需求}
\subsection{性能需求}
1.系统应具备高并发处理能力，能够同时支持至少1000个用户进行操作，确保在高峰时段用户请求能够得到及时响应，避免系统崩溃或响应延迟现象。

2.系统响应时间需保持在2秒以内，以提供用户以流畅的交互体验，无论是在进行商品浏览、下单支付还是订单跟踪等操作时，用户都应感受到快速且无缝的响应。

3.系统应保证99.9\%的高可用性，通过实施有效的故障转移和灾难恢复策略，确保系统在遇到硬件故障、网络问题或其他意外情况时，仍能继续提供服务，最小化系统停机时间。

\subsection{安全需求}
1.所有敏感信息的传输必须通过HTTPS等安全协议进行，利用SSL/TLS加密技术保护数据在传输过程中不被窃听或篡改，增强数据传输的安全性。

2.用户密码在存储前必须经过强哈希算法加密处理，以确保即便数据被非法获取，密码信息也难以被破解，保障用户账户安全。

3.系统需实施严格的访问控制机制，通过身份验证和权限控制确保只有授权用户才能访问相应资源，防止未经授权的访问和潜在的数据泄露风险。
\subsection{可用性需求}
1.系统界面设计应注重用户体验，采用直观且符合用户操作习惯的布局，减少用户的学习成本，使得用户能够轻松地找到所需功能并进行操作。

2.系统应支持主流的浏览器和操作系统，包括但不限于最新版本的Chrome、Firefox、Safari以及Windows和macOS操作系统，确保不同设备和系统环境下用户都能获得一致的使用体验。
\subsection{兼容性需求}
1.系统应兼容主流的移动设备和桌面设备，包括不同屏幕尺寸和分辨率的智能手机、平板电脑和电脑显示器，确保用户在各种设备上都能获得良好的视觉和操作体验。

2.系统应兼容不同的网络环境，无论是在4G、5G移动网络还是Wi-Fi环境下，都能保持稳定的性能和流畅的用户体验，不受网络波动的影响。
\subsection{可维护性和可扩展性需求}
1.系统设计应采用模块化和组件化的方法，使得各个功能模块之间保持低耦合性，便于未来的维护和升级，同时方便新功能的快速集成和部署。

2.系统应具备良好的可扩展性，能够适应未来业务增长和技术变革的需求，通过增加资源或进行少量修改即可实现功能的扩展和性能的提升。
\section{系统模型}
\subsection{类图}
类图如图~\ref{fig:10}~所示。
\begin{figure}[htbp]
\centering
\includegraphics[width=1.0\textwidth]{10}
\caption{类图}\label{fig:10}
\vspace{\baselineskip}
\end{figure}
\subsubsection{类图详细描述}
User（用户）

职责: 代表使用外卖平台服务的终端用户。

属性:username: 用户名，用于识别用户身份。

password: 密码，用于用户认证。

address: 用户的配送地址，用于订单配送。

方法:login(): 用户登录系统。

logout(): 用户登出系统。

placeOrder(): 用户下订单。

Restaurant（餐厅）

职责: 代表提供外卖服务的餐厅或商家。

属性:restaurantName: 餐厅的名称，标识不同的餐厅。

menuItems: 餐厅提供的菜单项列表。

方法:addMenuItem(): 向菜单中添加新的菜单项。

removeMenuItem(): 从菜单中移除某个菜单项。

Menu（菜单项）

职责: 代表餐厅可提供的具体菜品或商品。

属性:menuName: 菜单项的名称。

price: 菜单项的价格。

description: 菜单项的描述信息，包括成分、口味等。

方法:getDetails(): 获取菜单项的详细信息。

Order（订单）

职责: 代表用户在平台上下单的记录。

属性:orderId: 订单的唯一标识符。

user: 下订单的用户。

restaurant: 提供菜品的餐厅。

menuItems: 订单中包含的菜单项列表。

deliveryTime: 订单的预计配送时间。

方法:createOrder(): 创建一个新的订单。

cancelOrder(): 取消已创建的订单。

Payment（支付）

职责: 代表订单的支付信息。

属性:amount: 需要支付的金额。

paymentMethod: 支付方式，如支付宝、微信支付等。

方法:processPayment(): 处理支付请求。
\subsubsection{类之间的关系}
用户与订单: 一个用户可以下多个订单，但每个订单只属于一个用户。这表示了一种一对多的关系。

订单与菜单项: 一个订单可以包含多个菜单项，而每个菜单项可以被多个订单包含，表示了多对多的关系。

餐厅与菜单项: 一个餐厅提供多个菜单项，但每个菜单项只属于一个餐厅。这表示了一种一对多的关系。

订单与支付: 每个订单都需要一种支付方式，而每种支付方式可以用于多个订单。这表示了一种一对一的关系。
\subsection{数据流图}
数据流图如图~\ref{fig:11}~所示。
\begin{figure}[htbp]
\centering
\includegraphics[width=1.2\textwidth]{11}
\caption{数据流图}\label{fig:11}
\vspace{\baselineskip}
\end{figure}
\subsubsection{顶层数据流图}
顶层数据流图提供了“饿了吧V2.0”系统与外部实体之间数据流动的宏观视图。

用户：

动作：浏览菜单、下单、支付、查询订单。

数据流：用户操作数据流向订单处理模块，支付请求流向支付处理模块。

商家：

动作：注册、管理商品信息、处理订单。

数据流：商家操作数据流向商品信息管理模块。

系统：

处理：订单处理：接收用户订单，生成订单，处理支付。

商品信息管理：接收商家商品信息，更新商品数据库。

用户身份验证：验证用户身份，管理用户会话。

数据存储：用户数据库：存储用户信息。

订单数据库：存储订单信息。

商品数据库：存储商品信息。

外部系统：

支付网关：处理支付请求，返回支付结果。
\subsubsection{中层数据流图}
中层数据流图细化了顶层图中的某些处理过程，如订单处理和支付处理。

订单处理模块：

输入：用户选择的商品、数量、支付信息。

处理：生成订单详情、计算总价、处理支付请求。

输出：订单确认信息、订单状态更新。

支付处理模块：

输入：支付请求（包括订单金额、支付方式）。

处理：与支付网关交互，处理支付事务。

输出：支付结果，更新订单状态。
\subsubsection{底层数据流图}
底层数据流图详细描述具体的数据处理过程，例如用户身份验证和商品信息管理。

用户身份验证：

输入：用户提供的用户名和密码。

处理：验证用户凭证的正确性。

输出：登录成功或失败的确认信息。

商品信息管理：

输入：商家提供的商品信息（名称、价格、库存）。

处理：更新商品数据库，处理商品上架或下架请求。

输出：商品信息更新确认，商品列表更新。
\subsection{用例图}
用例图如图~\ref{fig:12}~所示。
\begin{figure}[htbp]
\centering
\includegraphics[width=0.7\textwidth]{12}
\caption{用例图}\label{fig:12}
\vspace{\baselineskip}
\end{figure}
\subsubsection{用例说明}
用户用例

用户注册

目的：允许新用户创建账户。

参与者：用户。

前置条件：用户访问注册页面。

后置条件：用户获得系统账户。

用户登录

目的：允许用户通过验证身份登录系统。

参与者：用户。

前置条件：用户已注册账户。

后置条件：用户获得系统访问权限。

浏览菜单

目的：允许用户查看可用菜单项和详情。

参与者：用户。

前置条件：用户已登录。

后置条件：系统显示菜单项。

下单

目的：允许用户选择商品并创建订单。

参与者：用户。

前置条件：用户已浏览菜单并选择商品。

后置条件：系统生成订单。

支付

目的：允许用户完成订单支付。

参与者：用户。

前置条件：用户已下单。

后置条件：订单状态更新为已支付。

查询订单

目的：允许用户查看订单状态和历史订单。

参与者：用户。

前置条件：用户已登录。

后置条件：系统显示订单详情。

商家用例

商家注册

目的：允许新商家创建账户。

参与者：商家。

前置条件：商家访问注册页面。

后置条件：商家获得系统账户。

商家登录

目的：允许商家通过验证身份登录系统。

参与者：商家。

前置条件：商家已注册账户。

后置条件：商家获得系统访问权限。

管理商品

目的：允许商家添加、修改或删除商品信息。

参与者：商家。

前置条件：商家已登录。

后置条件：系统更新商品信息。
\section{验收标准}
用户管理模块: 用户能够正常注册、登录、修改个人信息和管理地址。

商家管理模块: 商家能够正常注册、登录、管理店铺和商品信息。

点餐模块: 用户能够浏览商家菜单、添加商品至购物车并生成订单。

支付模块: 用户能够成功完成支付，订单状态正确更新。

订单管理模块: 用户能够查看订单状态并进行支付。

客服模块：用户能够和智能客服进行交流。